)

ExecuteActionWorkflowAsync previously called a private CompileRule(workflowName,
ruleName, ...) overload that always rebuilt the per-rule wrapper delegates from
scratch — no RulesCache lookup. With EvaluateRuleAction this turned every link
in a rule chain into a fresh compilation pass even when the workflow was
already registered.

This change routes the method through the same RegisterRule + GetCompiledRules
+ ApplyGlobalParams path that ExecuteAllRulesAsync uses. First call still
compiles; subsequent calls with the same workflow + param shape are cache hits.
Globals are evaluated once via the workflow-level cached delegate, matching
the existing microsoft#714 behavior.

Side cleanups:
- The now-unused private CompileRule(workflowName, ruleName, ruleParameters)
  overload is removed.
- EvaluateGlobalsAdHoc and CompileGlobalParamsDelegate are gone — the cache
  path supersedes them.

Benchmark (median of 5 runs, net8.0, 10-deep rule chain via EvaluateRuleAction):
  Chain x 100 invocations:     7 ms -> 3 ms   (~2.3x)
  Chain x 1,000 invocations:  65 ms -> 42 ms  (~1.5x)

The remaining time is delegate invocation + ActionContext setup; further wins
would need ActionContext JSON-serialization to be reworked, which is out of
scope here.

Also adds regression tests for both microsoft#471 and microsoft#513:
- Issue471Test verifies the cached path, chain correctness, and per-workflow
  cache-key isolation.
- Issue513Test documents the recommended OR-short-circuit pattern
  (NestedRuleExecutionMode.Performance under a single OrElse parent rule) for
  workflows that want "include if any rule matches" semantics.

All 160 unit tests pass on net6 / net8 / net9 / net10.